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(57) ABSTRACT 

A method for managing tasks in a data processing system 
having a shared task, which may be performed in hardware, 
software, or a combination of both. In response to a request 
from a requesting task, the task manager of the data pro- 
cessing system initiates performance of the shared task on 
behalf of the requesting task. At selected points in the 
performance of the shared task, the requesting task may 
cooperate with the shared task to selectively store 
watchpoints, each comprising sufficient information about 
the then-current status of the shared task to allow resumption 
of that task. During the performance of the shared task, the 
requesting task can determine if the shared task is still 
performing that task on behalf of the requesting task. If the 
requesting task determines that the task manager has inter- 
rupted the performance of the shared task on behalf of the 
requesting task prior to completion thereof, the requesting 
task may thereafter request the task manager to reinitiate 
performance of the shared task at the most recently stored 
watchpoint. 

12 Claims, 5 Drawing Sheets 
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SYSTEM 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates to task management in a 
data processing system, and specifically t o allocation o f a 
scared resource among multiple competing requests . 

2. Background Art 

In general, in the descriptions that follow, I will italicize 
the first occurrence of each special term of art which should 
be familiar to those skilled in the art of communication 
system security. In addition, when I first introduce a term 
that I believe to be new or that I will use in a context that I 
believe to be new, I will bold the term and then provide the 
definition that I intend to apply to that term. In addition, 
throughout this description, I will use the terms assert and 
negate when referring to the rendering of a signal, signal 
flag, status, bit or similar apparatus into its logically true or 
logically false state, respectively. 

Within a data processing system, the various hardware 
resources are usually controlled by low-level software 
modules, sometimes called drivers. Basic system functions, 
on the other hand, such as file or memory management, are 
performed by mid-level software modules that, in turn, may 
rely upon one or more of the drivers for actual hardware 

support. System level functions, such as application and 30 demands, additional application programs (not shown) may 
transaction management, are coordinated by upper-level be simultaneously active in the memory 14. 
software modules that may themselves rely upon one or "^^Various operating scenarios of the data processing system 
more of the lower level modules for support. This hierarchy 2, according to the prior art, are illustrated in FIGS. 2-4. In 
of system software modules is usually referred to as a Case I, illustrated in FIG. 2, OS 16 initiates a Process_^A 
operating system or OS. In general, an application program, 35 ("Start_A"), which may be either an application or system 

module. During execution, Process_A makes a request to 
the OS ("A_Request_R") for use of a shared resource, R, 
such as a particular shared task resident in the memory 14 or 
perhaps the resource 12. At this time, OS 16 initiates 
40 operation of the shared resource R ("A_Start_R"), which 
proceeds to perform its designated function. Upon initiating 
R, OS 16 stores information to identify Process_A as the 
current process utilizing resource R. While R is running, 

Process __A may perform other operations until some result 

^ stem or application, that performs a designated functi on 45 or response from R is required ("A_Read_R"). If R is not 
a ndhas regular structured input and regular stmctu red yet completed, Process_A must wait (indicated in FIG. 2 by 
output. For example, so long as an executing modul e (a the dashed vertical time line). Upon completion, R sends a 
re questing task^ can rnnctmrj the appro priate request to t he response to the waiting Process_^A ("R_Response_A"), 
TKT to in itial *»■ a par ticular task fa requested task ), the and Process_A is then able to continue. Simultaneously, R 
r equesting task doesn't care whether the requested ta sk 50 notifies OS 16 ("R_Stop^A") that it has compl6^d 
accomplis hes ihat L request entirely in softwar e, entirely in Process_A*s request. When Process_A finally completes 
hardware, or in a combination ol sohware ana Hardw are. ^2-i*s operation, it notifies the OS 16 ("A^_Stop"). 

FIG. 3 illustrates another prior art scenario, Case II, that 



Task _JC of Process _A and give il to, perhaps, a Task_S of 
a Process_B. Finally, assume that, before Task_R com- 
pletes the request from Task__X of Process^A, Tasle_S also 
requests that Task_R be performed. If, due 10 the nature of 
Task_R only one instant can be active at a particular point 
in time, then a resource conflict has occurred. A typical 
example is where Task_R "owns" exclusive rights to exploit 
a unique hardware or software component of the system. 
Access to Task_R must therefore be shared. This shared 
resource allocation problem can be further complicated if, 
for any of a number of valid reasons, each process (or each 
task within each process) is assigned a relative priority: what 
is to happen, for example, if Process_B has been assigned 
a higher priority than Process_A? 

FIG. 1 illustrates a conventional data processing system 2 
having a central processing unit or CPU 4 coupled to 
multiple special function units or SFUs, via a communica- 
tion bus 6. Any of a variety of functions may be imple- 
mented by SFU1 8 and SFU2 10, including arithmetic 
functions, logical functions, multimedia functions, etc. Each 
of SFU1 8 and SFU2 10 may perfomiasingle function, or 
may perform mulU^le fenctions^ Ao^idnall 
cessiflg--s^teTfi D 2 - tncTudes a resource 12, which may be^ 
mother processor, a memory, or a ny other device accessed 
d ata processing system^ 2^WitrmTa memory 14 is located 
an id, and at least one application program 18. Each 
application program 18 includes a scheduling block, and 

multiple tasks, such as Task 1 and Task_2. Depending 

upon various system resource constraints and workload 



such as a word processor or a browser, is comprised of one 
or more high-level modules which may, in the course of their 
execution, invoke either other application modules or OS 
modules, as needed, to perform specific functions. 

T he general process of module invocation a nd 
te rmination ,^USiJaHy referrqH tn as task management j s 
c oordinated by specific operating system modules, collec - 
t ively referred to as the T as k Manager or TM. From th e 
perspective of the TM. a task can be any software module, 




fF rom the perspective of the requesting task, therefo re, all 
l ower revel support tasks, whether software, n amware or 
b oth, can he cnnsidr .rrH as res ources. Task managemen t is 55 
t hus just a particular form of resourcemanagemen t. 4^ 

In multi-tasking data processing systems, multiple pro- 
cesses can be active simultaneously, although in a single 
processor system, only one of the active processes will be in 
control of the processor at any point in time. By way of 60 
example, assume that, at a particular point in time, a 

Process A is in control of the processor, and, in particular, 

that a Task_X of Process_A has just issued a request to the 
TM that Task _R be performed. Assume also that, since 
Task_R will take a relatively significant time to complete 65 
and that Task_X cannot proceed until Task_J* is completed, 
the TM will take control of the processor away from 



is similar to Case I, except that a Process_B is initiated 
("Start_B") after Process _^A has been initiated ("Start_ 
A"). During execution, Process_B also makes a request to 
OS 16 ("B _Request__R") for the use of resource R. At the 
time of this request, R is still performing the request from 
Process _A. If OS 16 has no mechanism for resolving the 
conflict or if both Process_^A and Process_B have the same 
or lower priority, Process_B must wait until R completes 
Process_^Vs request. Once R notifies OS 16 ("R_Stop_ 
A") that it has completed the request of Process_A, OS 16 
promptly initiates R for Process_B ("B_Start_JT). When 
resource R completes Process_B's request, it sends a 
response to the waiting Process__B ("R_Response_B"), 
which may now continue. Simultaneously, R notifies OS 16 
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("R__Stop_B") that it has completed Process_B's request. interrupted process when the higher priority process has 
For simplicity, the ultimate completions of Process_A and completed, or, if not, to simply restart the resource after the 
Process_B have not been shown. interruption. Usually, the choice is made at the time the OS 

FIG. 4 illustrates still another prior art scenario, Case in, is designed and cannot be changed to meet different system 

in which Process_B has been assigned a higher priority than s criteria. In order to make such decisions in a more effective 
Process_A In this case, when Process_B requests R ("B_ manner, either the TM must have access to additional 
Request_R")> OS 16 immediately initiates R for Process_B information regarding the nature of the requesting processes 
("B„Start_R"), thereby interrupting the operation of R for or the requesting processes themselves must be allowed to 
Process_A- When R completes, it sends a response to participate in the decision process. ^ >wxr^ 

Process_B ("R_Response„B"), and, simultaneously, noti- 10 There is need therefore for a method for allocating a S cSfg^^*^ *~ 
fies OS 16 ("R_Stop_JB") that Process_B's request is shared resource which allows each process some level of S 
complete. At that time, OS 16 reinitiates R for Process_A participation in the allocation decision by the TM. f ^y&—* — * J{ 
(the second "A_Start_R"). Additionally, a need exists for a more flexible method a t \ *^Z3^ v Jifi&*' 

As can be readily seen, the Case ID allocation policy may a llocating a shared resource to meet the timing of all V ^ ? c ^^° € " 

result in significant loss in system performance, due to the 15 processes in the system. \^J(^ ^^^^ * * * 

wasted time spent by R servicing the interrupted request of rimcc ctha^adv rn? -rue fm/cwnnNr 

Process_A. In pathological cases, the ProcL„A request SUMMARY OF THE INVENTION ^ (<? ^ 

may never be completed due to continual interruptions by My invention comprises a task management method in 

requests for R from higher priority processes. One prior art ^ which each requesting task is responsible for deciding on an 



solution is to provide a mechanism for R (or perhaps the appropriate course of action in the event the requested task 

requesting Process__Aor the OS itself) to periodically store is interrupted for any reason. Preferably, t he requestingj ask 

into the memory 14 a status "snapshot" or watchpoint i s capable of periodically requesting (and saving) the th en- 

consisting of sufficient information to allow later resumption c urrent status of the requested task, and the requesting ta sk 

should an interrupt occur. Then, should R be interrupted to i s capable of providing, if reque sted, sufficient status inlor- 
service a higher priority process, R can resume operation at 25 fnation to allow an interrupted tasK to De resumed. ~ At a 

the precise point at which the last watchpoint was taken. mini mum, the requested task must be able to inform the 

Thus, except in extreme circumstances, the interrupted pro- req uesting task as to the identity of the requesting task to 

cess will eventually complete. wh ich the requested task is then currently allocate d. Should 
In some systems, particular processes may have prede- 3Q the requesting task determine from such status information 

termined time windows within which they must complete. If that the requested task has been reallocated by the task 

the TM allows no resource interruption and reallocation, manager, the requesting task will invoke an exception han- 

such critical processes may miss their deadlines. For dler to deal appropriately with the situation, 

example, Process B might be a repeating process that m 

monitors an input"within a predetermined period, such as BRIEF DESCRIPTION OF THE SEVERAL 

looking for an incoming system status signal. Here VIEWS OF THE DRAWINGS 

Process_B has a brief window within which to catch the My invention may be more fully understood by a descrip- 

signal. If Process_A has initiated R, ProcessJ may not be tion of my i nven tion in conjunction with the attached 

able to satisfy its deadline if it is forced to wait until R has drawings in which - 

completed Processes request. Although tht prior art 4Q FI(J j iUmes in schematic diagram form a data 

watchpoint mechanism would allow Process B to interrupt ^ tem havi a cor6 processor> a shared 

Process A s use of R it assumes that, prior to interruption, [ m|ce ^ a me stQri an fi 

the watchpoint was indeed taken. Depending upon the size „ A . . 7. . 

of the watchpoint and the frequency with which they are FIGS. 2-4 illustrate m time line Torm prior art operations 

taken, significant system resources and performance may of a data processing system as in FIG. 1, where the operating 

thus be unavailable for application to more useful activities. svslem cootrols access to a shared resource; and 

One additional problem with prior art resource allocation FIG - 5 Urates in time line form the operation of a data 

mechanisms is that certain operations are inherently atomic Passing system as m FIG. 1 according to a preferred 

and are simply not amenable to interruption/resumption. The embodiment of my invention. 

higher priority requester may miss a deadline if it must wait 50 1° the drawings, similar elements will be similarly num- 

until a particularly long-running operation reaches a point at bered whenever possible. However, this practice is simply 

which it can be safely interrupted. For example, in some for convenience of reference and to avoid unnecessary 

serial communication systems, end-to-end synchronization proliferation of numbers, and is not intended to imply or 

must be maintained and therefore a transmission cannot be suggest that my invention requires identity in either function 
interrupted without loss of the entire transaction. Similarly, 55 or structure in the several embodiments, 

in a packetized transaction, used in many communication DETAILED DESCRIPTION OF THE 

networks, the packet transmission must be restarted alter INVENTION 
interrupt rather than resuming from the point of interrupt. 

The resulting degradation in system performance can be FIG. 5 illustrates task management according to my 
significant. $q invention. Initially, OS 16 initiates Process_A("Start_A"). 

In all of these cases, the TM is required to dynamically At some time thereafter, Process_A requests the use of R 

allocate and, perhaps, reallocate shared resources. Should a from OS 16 ("A_Request_R")> which thereupon initiates R 

conflict occur, the TM must first decide whether to allow ("A_Start_R")- A bit later in time, OS 16 initiates 

Process__A's use of the resource to continue to completion, Process_B ("Start_B")- 

or to interrupt it so that Process_B can use the resource. If 65 While resource R is still processing the request from 

the latter choice is made, then the TM must determine if Process__A, Process__A reads R (the first instant of 

there is a recent watchpoint which can be used to resume the "A__Read_R"), and, in response, R returns it's then-current 
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status (the first instants of "Status_R"), including the ID of 
the requesting task to which R is allocated. At this point, this 
TaskJD verifies that R is allocated to Process^. In 
addition, the status information may include sufficient state 
information to allow resumption of R in the event of 
reallocation prior to completion of Process_A , s request. In 
such case, Process _A is responsible for saving such state 
information (or, at a minimum, providing to R a pointer to 
a storage area at which R can store the watchpoint). 
Preferably, the read request issued by Process_A to R will 
include a corresponding signal which can be optionally 
asserted by Process_A to request transfer to Process_A of 
the watchpoint. Thus, only those requesting tasks that antici- 
pate possible interruption and resumption will require trans- 
fer of the full watchpoint, thereby reducing interprocess 
communications and improving system performance. 15 
At a later point, Process_J3 requests use of R ("B_**> 
Request„R"). Assuming that OS 16 decides that Process_B 
is entitled to immediate use of R, OS 16 will initiate R for 
Process__B ("B_Start_R"). When R completes, it sends a 
response to P 
simultaneously, 
"rocess_B , s rec 



In an alternate embodiment of my invention, R can, at the 
option of the particular requesting task to which R is 
then-currently allocated, periodically save the watchpoint to 
a storage area uniquely assigned to that requesting task, with 
each subsequent watchpoint overwriting the previous watch- 
point. In the event that a interruption occurs, the requesting 
task has only to request resumption (rather than reinitiation), 
and R wilTbe able to unambiguously find and load the 
appropriate watchpoint. However, in order to minimize 
system overhead, each requesting task should request watch- 
point saves only if and when necessary and appropriate 
under the circumstances, 
V3> In accordance with my invention, a task management 
system is provided in which: a Jirst task m a v be preempted 
15 fay a second task, including its use of a resource; eac h 
pre emption of a use of a resource can be d etected at the 
pr ecise point of such preemption; a task's use of a resourc e 
can be precisely tracked includi ng anv preemption of such 



use; and a ta *fr ran he tirnely notified tfr^ a use of a resource 
Process_B ("R_Response__B"), and, 20 h as been preempte d. As a result, it is no longer essential that 
notifies OS 16 ("R_Stop_B") that the TM save or restore resource context during a task switch; 
request is complete. tZ- instead, each task assumes responsibility for performing this 



In deciding whether or not to interrupt Processor's use function as appropriate. Further, each requesting task can 

~ ' J - include an exception handler specially adapted to deal with 

25 the unique requirements and nature of that task, taking into 
account the relevant task and resource preemption informa- 
tion maintained by, and available from, the TM. As a result 
of having each requesting task assume responsibility for 
deciding how to proceed in the event a requested task must 
be interrupted, the OS can be significantly simplified, and 



of R, OS 16 will need to take into consideration various 
conditions. Fnr e/yarnple, process B mav have be en 
as signed a hig her priority than Process A, Process_B m ay 
have an earlier deadline than Process A. or Process Bmav 



35 



al ready be using some o ther resource, such that allowing it 
t o be blocked by Process^A could lead to a deadlock. One 
possible scheme requires each requesting process, w hen it 

is sues a request to add a requested process to the system , to -p V thiis made more efficient in operation, 
de clare a schedule for the requ ested process, in terms oLlhe ^illeH in the art will recoeni 

n umber of times per second it m ust he allowed to run its 
i nterval the percentage o f CPU time it requires each interval 
(its utilization ), and the resourc e* U requires during the 

interval. It, in respo nse to ear'h r^qn^t tr. «HH a reqn estarl 
process to the system, th e Tfyf determines that it cannot meet 
the de clared schedule and still continue to meet the require - 
m ents ot' all existing processes, it must refu se to start the 
reque sted process; but the requesting proc ess mav reissue 
the reqiiest with a different irhr duk. Tn ^th^r words, before 
a "requested process can be added to the set of available 
processes, the TM must determine that it can meet their 
combined utilization and resource requirements, as well as 
guarantee that their scheduling intervals or deadlines will be 
met. In general, however, the TM may still have to preempt 
a process with a longer interval (say, a Process_C) to 
guarantee that a process with a shorter interval (say, a 
Process_D) meets its deadlines. If, for example, Process_C 
and Process_D both require the same resource R, then 
Process__D may preempt Process_C , s use of R any time it 
preempts Process_C. 

While R is processing Process_B's request, Process__A 
again reads R (the second instant of "A_Read_R"), and, in 
response, R returns it's then-current status (the second 
instant of "Status_R")- This time Process_A determines 
that R is no longer processing it's request, but is instead 
processing Process __B's request. In response, Process__A 
initiates an exception handler to determine what action is 
appropriate under the specific circumstances. For example, 
the exception handler may decide to simply initiate another 
request for R to OS 16. Alternatively, the exception handler 
may decide to retrieve from storage the most-recent watch- 
point (i.e., the first instant of "Status_K")> and to forward a 
pointer to this information to OS 16, together with a request 
to have R resume processing from the point at which the 
watchpoint was taken. 
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Those skilled in the art will recognize that other modifi- 
cations and variations can be made without departing from 
the spirit of my invention. Therefore, I intend that my 
invention encompass all such variations and modifications 
as fall within the scope of the appended claims. 
What I claim is: 

1. In a multi-tasking data processing system in which a 
first task may request performance of a shared task, a task 
management method comprising the steps of: 

initiating performance of said first task; 
in response to a first request from the first task, initiating 

performance of said shared task for said first task; 
interrupting performance of said shared task for said first 
task; 

in response to a second request from the first task: 
reinitiating performance of said shared task for said 
first task, if said second request requests such reini- 
tiation; but 

resuming performance of said shared task for said first 
task at a selected point of resumption of operation, if 
said second request requests such resumption; 
completing performance of said shared task for said first 
task; and 

completing performance said first task. 

2. The method of claim 1 further comprising the step of: 
storing at least one watchpoint of said shared task, said 

watchpoint comprising sufficient information to resume 
performance of said shared task from a respective point 
of operation; 

wherein, if said second request requests resumption of 
said snared task, said second request selects said watch- 
point as said point of resumption of operation. 

3. The method of claim 2 wherein the step of storing is 
further characterized as: 
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selectively storing at least one watchpoint of said shared 
task, said watchpoint comprising sufficient information 
to resume performance of said shared task from a 
respective point of operation. 

4. The method of claim 3 wherein the first task cooperates 
with the shared task in the selective storing of said watch- 
point. 

5. A task management method comprising the steps of: 
initiating performance of a first task; 
in response to a first request from the first task, initiating 

performance of a shared task for said first task; 
interrupting performance of said shared task for said first 
task; 

in response to a second request from the first task: ^ 
reinitiating performance of said shared task for said 
first task, if said second request requests such reini- 
tiation; but 

resuming performance of said shared task for said first 
task at a selected point of resumption of operation, if 20 
said second request requests such resumption; 
completing performance of said shared task for said first 
task; and 

completing performance said first task. 

6. The method of claim 5 further comprising the step of: 
storing at least one watchpoint of said shared task, said 

watchpoint comprising sufficient information to resume 
performance of said shared task from a respective point 
of operation; 

wherein, if said second request requests resumption of 
said shared task, said second request selects said watch- 
point as said point of resumption of operation. 

7. The method of claim 6 wherein the step of storing is 
further characterized as: 

selectively storing at least one watchpoint of said shared 
task, said watchpoint comprising sufficient information 
to resume performance of said shared task from a 
respective point of operation. 

8. The method of claim 7 wherein the first task cooperates 40 watchpoint. 
with the shared task in the selective storing of said watch- 
point. 
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9. In a multi-tasking operating system in which a first task 
may request performance of a shared task, a task manage- 
ment method comprising the steps of: 

initiating performance of said first task; 
in response to a first request from the first task, initiating 

performance of said shared task for said first task; 
interrupting performance of said shared task for said first 
task; 

in response to a second request from the first task: 
reinitiating performance of said shared task for said 
first task, if said second request requests such reini- 
tiation; but 

resuming performance of said shared task for said first 
task at a selected point of resumption of operation, if 
said second request requests such resumption; 
completing performance of said shared task for said first 
task; and 

completing performance said first task. 

10. The method of claim 9 further comprising the step of: 
storing at least one watchpoint of said shared task, said 

watchpoint comprising sufficient information to resume 
performance of said shared task from a respective point 
of operation; 

wherein, if said second request requests resumption of 
said shared task, said second request selects said watch- 
point as said point of resumption of operation. 

11. The method of claim 10 wherein the step of storing is 
further characterized as: 

selectively storing at least one watchpoint of said shared 
task, said watchpoint comprising sufficient information 
to resume performance of said shared task from a 
respective point of operation. 

12. The method of claim 11 wherein the first task coop- 
erates with the shared task in the selective storing of said 
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